More Related Content
Similar to 10 fn s44 (20)
More from Scott Foster (20)
10 fn s44
- 1. Ethernet OAM: A Case Study
Version 1
Mike Bencheck
Principal Member of Technical Staff
Verizon Core Network Technology
mike.bencheck@verizon.com
© Verizon 2010 All Rights Reserved Page - 1
- 2. Agenda
• Ethernet Service OAM Drivers
• Service OAM Standards
• Verizon Interoperability Forum (VIF)
• VIF Lessons Learned to Date
• Standards
• Implementation
• Management
• Notifying a customer of a fault
• Conclusions
© Verizon 2010 All Rights Reserved Page - 2
- 4. Drivers for Ethernet Service OAM
Ethernet services are being widely adopted by customers and
Service Providers
Customers have high expectations for Carrier Ethernet
– Premium services over Ethernet
• Voice
• Mission Critical Data
– Expect SLAs
– Use as TDM replacement
Service Providers need end to end visibility to Ethernet service
– Allow management of Ethernet similar to TDM services
• Isolation of service affecting defects
• Functions like link trace and loopback
– Provide customer notification of EVC faults
Support end to end SLA measurement
– Performance characteristics
• Frame Loss Ratio
• Frame Delay
• Inter-Frame Delay Variation
• Availability
• Throughput
© Verizon 2010 All Rights Reserved Page - 4
- 6. Ethernet Service OAM Standards
Two standards
– IEEE 802.1ag
• Fault Management
– ITU-T Recommendation Y.1731
• Fault and Performance Management
Differences exist between the two standards
– Identified via MEF and liaisons sent to both bodies to address
Standards define monitoring points on a per EVC basis
– Monitoring End Point (MEP)
• Upward facing
• Downward facing
– Monitoring Intermediate Point (MIP)
Standards define eight levels of monitoring
– Supports nesting of monitoring points
– Levels assigned to Subscriber, Service Provider, Operator and Link
Define Performance Measurement, Continuity Verification, Link
Trace and Loopback functionality
– Supports traditional OAM features from legacy services
© Verizon 2010 All Rights Reserved Page - 6
- 9. Ethernet OAM Verizon Interoperability Forum
VIF is a forum where multiple vendor implementations are tested
for interoperability
– Ethernet OAM VIF focus is on
• IEEE 802.1ag
• ITU-T Y.1731
• IEEE 802.3, Clause 57
• MEF E-LMI (MEF 16), SOAM-FM and SOAM-PM Interworking Agreements
VIF format is useful in eliminating unclear areas in standards
– Agreements on interpretation of standards
– Multiple vendors participate
– Recommendations to standards based on findings
Ethernet OAM VIF testing is being done in the Verizon
Prototyping Facility in Richardson, TX
2009 focus was Fault Management
– Nine vendors
– IEEE 802.1ag
– ITU-T Y.1731 AIS
– Loopback
– Linktrace
2010 focus is Performance Management
– Performance metrics
– Time of Day synchronization
© Verizon 2010 All Rights Reserved Page - 9
- 13. Lessons Learned
Standards
– Differences between IEEE and ITU-T service OAM standards mean they cannot
interoperate
• Naming
– Differences in MAID versus MEG
» MEG ID defined in Y.1731 as 13 character ICC-based field
» MAID is defined in 802.1ag as up to 43 characters
• Link Trace
– Differences in LTR
» Y.1731 does not use the Relay Action field
» 802.1ag requires use of the Relay Action field
– Vendor support for IEEE leading ITU-T
• Naming convention issues may introduce requirement for migration
– Implementation of performance monitoring portion of Link OAM limited
– MEF standards defining different MD levels than used in testing
• MD Level 1 for UNI ME versus MD level 0 as an example
© Verizon 2010 All Rights Reserved Page - 13
- 14. Lessons Learned
Implementation
– Support for both Up facing and Down facing MEPs required
• Some interfaces must support Up and Down MEPs at different MD levels
– Support for MIPs is required
• Customer and network facing ports
– Untagged MEPs
• Most vendors can not support on interfaces configured for tagging
• Requires using tagged MEPs a MD Level 0 or 1
• Tagged CCMs can be blocked by STP
– Need to define Local and Remote MEPIDs per MA
• Auto-discovery leaves possibility of MEPs being added to wrong MA and working with
other MEPs in MA
• Not all vendors support auto-discovery
– IEEE format naming convention for MDs and MAs allows link to service ID
– Continuity Check interval < 1 second not supported by many vendors
• If used as fault detection method, 3 second minimum detection time
• Not fast enough for all customer requests
– Some requests for sub-second notification
– Where NIDs create tunnels and are not service aware, monitoring services is not
supported
• Still researching methods to monitor tunnel
© Verizon 2010 All Rights Reserved Page - 14
- 15. Lessons Learned
Management
– Provisioning of OAM across network is complex
• OAM provisioned on a service type basis
– Placement of MEPs and MIPs
– Reaction to fault notifications
• Not practical to manually configure in production
• Requires network wide view of services and Network Elements
– NMS for OAM may be required
• Provides cross vendor provisioning capabilities
• Can use vendor EMS or connect directly to NEs
© Verizon 2010 All Rights Reserved Page - 15
- 16. Lessons Learned
Customer Fault Notification Methods
– Two methods reviewed to notify customers of a fault on an EVC
• AIS
– Defined in ITU-T Y.1731
• E-LMI Async Status Message
– Defined in MEF 16
– Each can accomplish the same thing
• Implementation will depend on what customer equipment supports
– Service Providers want to offer the most flexibility
– May need to support both options
© Verizon 2010 All Rights Reserved Page - 16
- 17. Fault Notification using AIS
Fault detected at Level 0
Propagates to defined client level (6)
AIS sent to customer equipment
© Verizon 2010 All Rights Reserved Page - 17
- 18. Fault Notification using E-LMI
Fault detected at Level 0
Propagates to NID
E-LMI asynchronous status message sent to customer
equipment
© Verizon 2010 All Rights Reserved Page - 18
- 20. Conclusions
Ethernet OAM is becoming increasingly critical to
achieve carrier class Ethernet networks
Verizon testing shows basic interoperability
– Fault Management
– Continued equipment vendor development required to meet all
carrier and customer expectations
Lessons learned
– Standards require minor modifications
• Interoperability between IEEE and ITU-T
– Implementation of standards is complex in a carrier network
• Requires external management system to understand deployment
• Requires equipment vendors to continue development of new
features/functions to match changes in standards
© Verizon 2010 All Rights Reserved Page - 20
- 21. Thanks
© Verizon 2010 All Rights Reserved Page - 21